8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / compuserve-file-archive / 03 Demos and Info / BPLUS.DOC < prev next >

Wrap

Text File | 2019-04-13 | 70.4 KB | 2,079 lines

The CompuServe B Plus Protocol May 16, 1988 2:10 PM by Russ Ranshaw TABLE OF CONTENTS A. Introduction. B. Notation. C. B Plus Packets. 1. B Plus Packet Structure. 2. Quoting of characters. 3. Check Value. 4. B Plus Packet Types. a) Packet Type `+': Transport Parameters. b) Packet Type `T': File Transfer. c) Packet Type `N': Data. d) Packet Type `F': Failure. e) Optional `T' Packets. 1) Packet `Tr' : Download Resume. 2) Packet `Tu' : Upload Resume. 3) Packet `Tf' : Failed CRC. 4) Packet `TI' : File Information. D. B Plus Control Sequences. 1. Enquire. 2. Positive Acknowledge. 3. Wait. 4. Negative Acknowledge. 5. Panic Abort. E. Negotiation of Transport Parameters. F. Terminal Program States. G. Wait for Acknowledge. H. Packet Send Ahead I. Implementation Considerations 1. Time-Out 2. Packet Size. 3. Controlling Excessive Retransmissions. J. B Plus Transport Layer. K. Initiation of a B Plus Session. L. Supporting the Various B Protocol Versions M. Check Value Calculation. 1. Standard B Protocol Checksum. 2. XMODEM-Style CRC-16. N. Interrogation. A. Introduction. The CompuServe B protocol was developed in 1981 to provide support for a special purpose Vidtex terminal manufactured by the Tandy Corporation. It was the outgrowth of a proposed Bi-Sync oriented protocol, but with a different packet structure and provision for more than even and odd packets. The file transfer capability was added in 1982 to replace the CompuServe A protocol with a more robust protocol which was in keeping with the over-all B Protocol design. Some of the underlying assumptions made in designing the B Protocol were due to the capabilities of personal computers which were available at the time. Such machines were generally limited in the amount of available memory, 64 kilobytes being a large capacity. Other factors, such as the lack of a true UART for data communications, resulted in the send/wait nature of the protocol where only a single protocol packet at a time was sent. The explosive growth of the Personal Computer industry has given us a plethora of machines, most of which have far exceeded the early limitations of memory and communication ability. This growth has been accompanied by a multitude of file transfer protocols, such as XMODEM, KERMIT, and ZMODEM. CompuServe, realizing the need for enhancement, has developed the B Plus Protocol to meet the increasing demands being made upon its communication network and host computers, and to provide added utility for its large family of users. As the name implies, B Plus is an extension of the B Protocol. In particular: o Ability to send multiple packets without waiting for individual acknowledgements. o Larger data packets (up to 1k at present). o Optional use of modified XMODEM CRC-16 check method. o Extensions to the standard control character quoting. o Provision of a mechanism to exchange transport and application parameters. 2 B. Notation. Throughout the remainder of this document the following notational conventions will be used: o Protocol elements are enclosed within angle brackets. For example: <DLE> specifies the ASCII code for Data Link Escape. o The C-language notation for hexadecimal values will be used. Thus, the <DLE> character will also be shown as 0x10. Two entities (computers) are involved in a B Plus session. The term "Initiator" is used to refer to the entity which initiates the session. "Responder" refers to the entity which receives the initiate command. CompuServe host computers will always be the Initiator in any communication established with them. For further information regarding Host support, see Section "K. Initiation of a B Plus Session." 3 C. B Plus Packets. 1. B Plus Packet Structure. B Plus Protocol packets consist of five parts as follows: o Lead-in <DLE> <B> o Sequence <0x30 thru 0x39> o Type <Single byte> o Body <zero to 1024 data bytes> o Trailer <ETX> <Check Value> The Sequence is incremented by one for each successfully transmitted packet. It wraps from 0x39 back to 0x30. (Note that 0x30 is the ASCII character 0 and 0x39 is 9.) The Sequence, Type, all Body data, and <ETX> are included in the Check Value. Note that <Body> and <Check Value> are Quoted, and that the Check Value is computed on the actual data bytes rather than their quoted replacements (the quoting <DLE> is not included). Hence, if the character 0x13 is to be sent, it is sent as <DLE> <S> but the value 0x13 is included in the Check Value. If Standard Checksum is used, <Check Value> consists of a quoted byte. If the XMODEM CRC-16 is used, <Check Value) is transmitted as two quoted bytes with the most significant byte appearing first. By performing the CRC calculation on the XMODEM CRC-16 value, the result will be 0x0000 if no errors occured. A sample B Plus packet, sent using the Standard Checksum, is as follows: <DLE> B 7 T D A S . C <ETX> 0x2A 0x10 0x42 0x37 0x54 0x44 0x41 0x53 0x2E 0x43 0x03 0x2A where Lead-in = <DLE> B Sequence = 7 Type = T Body = DAS.C Trailer = <ETX> 0x2A If the packet was sent using the XMODEM CRC-16 option, the Check Value would be 0x57 0xFF instead of 0x2A. 4 2. Quoting of characters. The B Plus Protocol quotes certain ASCII control characters. The default set of quoted characters is: o <ETX> 0x03 o <ENQ> 0x05 o <DLE> 0x10 o <DC1> 0x11 o <DC3> 0x13 o <NAK> 0x15 The quoting mechanism uses the <DLE> character to prefix the quoted character. The quoted character with 0x40 added follows the <DLE>. For example, <ETX> is quoted as: <DLE> C 0x10 0x43 B Plus also provides a means for the Initiator and Responder to establish a different set of quoted characters. This set may consist of any or all characters in the ranges 0x00 thru 0x1f and 0x80 thru 0x9f. Quoted characters in the 0x80 thru 0x9f range are sent as: <DLE> ((char and 0x1f) + 0x60) Hence, 0x93 is quoted as: <DLE> s 0x10 0x73 When receiving protocol data, the program should be capable of decoding any quoted character, regardless of the set of quoted characters in use. This must be accomplished as follows: Get a character. If the character is <DLE> then Get next character. If character is less than 0x60 then character = character and 0x1f else character = (character and 0x1f) + 0x80 5 3. Check Value. Each B Plus packet contains a Check Value to allow detection of transmission errors. The B Plus Protocol supports two Check Value methods as follows: a) Standard B Protocol Checksum. The Standard Checksum is calculated as follows: o The checksum is initialized to zero. o For each byte that is to be checksummed: - The old checksum is rotated left 1, with the old bit 7 becoming bit 0 in the rotated value. - The new byte is added to the rotated checksum. - If addition of the new byte causes a carry, then one is added to the new value. b) XMODEM-Style CRC-16. B Plus implementations may optionally specify that the defacto standard XMODEM CRC-16 be used as a check value. The only departure is that the CRC-16 value is initialized to 0xffff instead of zero. Sample C code for calculating these Check Values is presented in Section "H. Check Value Calculation." 6 4. B Plus Packet Types. The following Packet Types are the minimum required to support the B Plus Protocol: o `+': Transport Parameters o `T': File Transfer o `N': Data o `F': Failure a) Packet Type `+': Transport Parameters. This is the B Plus Transport Parameters Packet. It describes an entity`s Transport capabilities. The Transport Parameters Packet is always sent with all characters in the ranges 0x00 thru 0x1f and 0x80 thru 0x9f quoted, and using the Standard Checksum. The Body of the <+> packet is a series of bytes as follows: WS WR BS CM DQ TL Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 DR UR FI where: WS = Window Send. 0x00 implies that a single packet at a time can be sent, 0x01 two packets. The default is 0x00. WR = Window Receive. 0x00 implies that the entity cannot receive other than a single packet at a time (that is, requests the other entity to use WS = 0x00); 0x01 implies two packets. The default is 0x00. BS = Block Size. This specifies the maximum size of the <Body> divided by 128. Thus 0x04 represents 512 bytes and 0x08 is 1024 bytes. The value 0x00 implies the default size of 512 bytes. CM = Check Method. 0x00 is standard checksum; 0x01 is XMODEM CRC-16 initialized to 0xffff. Note that CompuServe recommends the use of CRC-16 instead of the standard checksum due to its superior error detection capability. The default is Standard Checksum, 0x00. 7 DQ = Data Quoting Level. This parameter is part of an interim version of the B Plus Protocol. It has been superceeded by the eight byte Quoting Set in Parameters Q1 thru Q8 (below). For historical purposes, the Quoting Levels are: 0x00: 0x00 0x03 0x05 0x10 0x11 0x13 0x15 0x01: 0x03 0x05 0x10 0x11 0x13 0x15 0x02: 0x03 0x05 0x10 0x11 0x13 0x15 0x91 0x93 0x03: 0x00 thru 0x1f and 0x80 thru 0x9f If a Parameters packet contains Q1-Q8, the DQ must be ignored and the quoting set established from Q1-Q8. If Q1-Q8 are absent, the above definitions must be used. TL = Transport Layer. The Initiator sets the TL parameter to 0x01 when it is running an application that must run under the Transport Layer. If the Responder`s half of the application also utilizes the Transport Layer, it must also set the TL parameter to 0x01. The default value is 0x00. More information is in Section "J. B Plus Transport Layer." Q1-Q4 = A mask indicating which characters in the range 0x00 thru 0x1f the entity wants quoted. The mapping of bits to characters is: Bit: 7 6 5 4 3 2 1 0 ----- ---- ---- ---- ---- ---- ---- ---- ---- Q1: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 Q2: 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f Q3: 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 Q4: 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f CompuServe Hosts currently use: 0x14 0x00 0xd4 0x00 Q5-Q8 Same as Q1-Q4 for the range 0x80 thru 0x9f. CompuServe Hosts currently use: 0x00 0x00 0x00 0x00 DR Download Resume. 0x00 : Download Resume not supported 0x01 : Supports `Tr' Packet 0x02 : Supports `Tr' and `Tf' Packets 8 UR Upload Resume. 0x00 : Upload Resume not supported 0x01 : Supports `Tu' Packet 0x02 : Supports `Tu' and `Tf' Packets FI File Information. This parameter specifies the level of extended file handling supported. 0x00 = No extended file handling 0x01 = `TI' (File Information) Packet These are the currently defined Transport Layer Parameters. CompuServe reserves the right to define additional parameters at any time. Programs should be capable of accepting any number of parameters. Received parameters beyond the known ones must be ignored. If fewer Transport Parameters are received than the entity understands, then any beyond the last received parameter must be treated as if it was provided as 0x00, which must be its default value. See Section "E. Negotiation of Transport Parameters" for details on deciding what level of capabilities each entity is to use. 9 b) Packet Type `T': File Transfer. The File Transfer Packet consists of three fields as follows: <Direction> <Data type> <File name> 1) Function. `D' = Download (Initiator -> Responder) `U' = Upload (Responder -> Initiator) `C' = Close. End of Upload or Download (Note: Additional "T" packets are defined later.) 2) Data type. `A' = 7-bit ASCII data. (Allows for End of Line conversion.) `B' = 8-bit Binary data. `I' = Image data. (This is hardware specific data and usually consists of some embedded header which describes the remainder of the file. It is always 8-bit binary data.) 3) File Name. This field is variable length and specifies the name of the file to be transfered. A sample File Transfer packet using CRC Check Method is: <DLE> B 7 T D A S . C <ETX> 0x57 0xff 0x10 0x42 0x37 0x54 0x44 0x41 0x53 0x2e 0x43 0x03 0x57 0xff which specifies: o `T': File Transfer o `D': Download to the Responder o `A': This is an ASCII file o `S.C': The file name Note that there are no guidelines as to what the Responder is to do with the File Transfer packet. In particular, the implementor is free to locally verify the request, permit the file name to be changed, etc. If the Responder does not wish to comply with the request made in the File Transfer packet, a Failure Packet must be returned to the Initiator. 10 c) Packet Type `N': Data. This is a data packet. The data being transferred is broken up into a series of <N> packets. There may be zero to the negotiated data block size. A count of zero does not imply end of file. d) Packet Type `F': Failure. This is the general Failure Packet. A Failure Packet may be sent at any time; the value of the <Sequence> field is ignored. The first character of the <Body> indicates the general nature of the failure, and the remainder may be a printable ASCII message further describing the condition. The following standard failures must be supported: `A': Abort. Usually sent if the user requests that the terminal program cease tranferring data. `C': Capacity failure. Out of memory or disk. `E': Processing error. Any error other than described by another Failure Packet. `I': I/O error occured. `M': File requested for Uploading is Missing (not found). `N': Unimplemented Packet Type was received. `S': Protocol Sequence Number failure. `r`: Transfer Resume failure. When a Failure Packet is received, it must be acknowledged and the transfer aborted. Similarly, when a Failure Packet is sent, the sending entity must wait for the acknowledge to arrive. In addition, the entity which sends the Failure Packet must ignore all other packets while waiting for the acknowledgement to arrive. Once the Failure Packet is successfully transfered, both entities are expected to leave protocol mode. 11 e) Optional `T' Packets. Several "T" Packets may optionally be supported. The support for these packets is specified by the DR, UR, and FI Transport Parameters. 1) Packet `Tr' : Download Resume. When the Responder receives the "TD" (Download Request) packet and the specified file already exits, it may attempt to resume the download which was aborted during a prior session. In order to do this, both entities must specify Transport Parameter DR > 0x00. If the Responder attempts the resumption, a `Tr' Packet is returned to the Initiator as follows: <DLE> B <Sequence> T r <Length> <CRC-16> <ETX> <Trailer> where: <Length> = current number of bytes in Responder's existing file. <CRC-16> = XMODEM CRC-16, initialized to 0xffff, of all existing data in Responder's file. Both <Length> and <CRC-16> are transmitted as an ASCII decimal string and are both followed by at least a single space. The Initiator will perform the same CRC-16 calculation over <Length> bytes and compare the resulting CRC-16 values. If the calculated and `Tr' values agree, downloading continues with `N` Packets and Responder appends the data to the existing file. If the files match exactly, a `TC' (Transfer Close) packet is sent. If the CRC-16 values do not match, or the Initiator's file be shorter than <Length> bytes, the Initiator's response depends on the value of the DR Transport Parameter: 0x01 - A `Fr' (Failed Resume) Packet is sent 0x02 - A `Tf' (CRC Failed) Packet is sent Some operating environments complicate Download Recovery. Since the Initiator has no knowledge of any data transformations, such as Carriage Return and Line Feed mappings, the Responder must take any such transformations into consideration when calculating <length> and <CRC-16>. Under some environments, it is probably simpler to maintain this information during the download and preserve it in a file (Apple Macintosh (TM) for example.) 12 2) Packet `Tu' : Upload Resume. The Upload Resume Packet is sent by the Initiator if both entities have the Transport Parameter UR > 0x00, the target file already exists on the Initiator, and the application software has decided to attempt an upload resumption. It is essentially a `TU' Packet with <length> and <CRC-16> fields. It is constructed as follows: <Lead-in> <Sequence > T u <Data Type> <Length> <CRC-16> <File Name> <Trailer> where: <Data Type> = same as for the `TU' Packet <Length> = number of bytes in existing file on Initiator <CRC-16> = XMODEM CRC-16, initialized to 0xffff, of all <Length> bytes <File Name> = same as for the `TU' Packet The Responder opens <File Name> and calculates the CRC-16 for <Length> bytes. If the resulting CRC-16 agrees with <CRC-16> from the `Tu' Packet, it continues by sending `N' Packets. If the CRC-16 values do not match, the action depends on the value of Transport Parameter UR: 0x01 - A `Fr' (Failed Resume) Packet is sent 0x02 - A `Tf' (Failed CRC) Packet is sent The same operating environment considerations mentioned under the `Tr' Packet apply here. 13 3) Packet `Tf' : Failed CRC. The `Tf' packet is sent when a Resume request fails due to CRC failure. It will be sent only if the Responder and Initiator both specify Transport Parameter DR > 1. It implies that the transfer is to continue from the beginning of the file. Sample packet exchanges for transfer resumption: Initiator Responder Comments --------- --------- ----------------- DR = 0x01 or 0x02: TD ---------------> Download Request <--------------- Tr Resume Download N ---------------> CRC matched ... TC ---------------> End of transfer DR = 0x01: TD ---------------> Download Request <--------------- Tr Resume Download Fr ---------------> Resume failed DR = 0x02: TD ---------------> Download Request <--------------- Tr Resume Download Tf ---------------> CRC mismatched <--------------- ACK Transfer entire N ---------------> Data ... TC ---------------> End of transfer UR = 0x01 or 0x02: Tu ---------------> Upload Resume <-------------- N CRC Matched ... <-------------- TC End of transfer UR = 0x01: Tu ---------------> Upload Resume <--------------- Fr CRC mismatch UR = 0x02: Tu ---------------> Upload Resume <--------------- Tf CRC mismatch ACK---------------> Transfer entire FIle <--------------- N Data ... <--------------- TC End of transfer 14 4) Packet `TI' : File Information. The `TI' Packet is transmitted by the File Sender, provided that both entities have their Transport Parameter FI > 0x00. It is used to convey specific data concerning the file as it exists on the Sending entity. The format of the `TI' Packet is as follows: <Lead-in> <Sequence> T I <data type> <compression > <file length> <creation date> <creation time> <modification date> <modification time> <true name length> <true name> <Trailer> where: <data type> : A = ASCII, B = Binary. <compression> : Specifies how the file is compressed during transmission (has nothing to do with the content of the file). 0x00 = not compressed (other values reserved for future use by CompuServe) <file length> : Current length of the file being sent. (Actual number of file data bytes being sent, not the number of compressed bytes). This value is passed for display display or media check only. <zone> : Minutes offset from UCT of Sender. <creation date> : Date the file was created. ASCII decimal string, yyyymmdd <creation time> : Time of day the file was created. ASCII decimal string, seconds since midnight. <modification date> : Date the file was last modified. Same format as <creation date>. (`0' if unknown) <modification time> : Time of day the file was last modified. Same format as <creation time>. (`0' if unknown) <true name length> : Number of bytes in <true name>. (This is a single binary byte.) <true name> : The actual file name with any device, directory, or other ancillary information removed. It is not necessary that all fields be transmitted. 15 A sample TI packet (file information only) is: "A?55387 300 19880422 52480 0 0 ?BPLUS.DOC" | | | | 0x00 EST 7:18 PM 0x09 D. B Plus Control Sequences. The B Plus Protocol defines several Control Sequences in addition to packets. Control Sequences are used to manage the progress of the B Plus Session. 1. Enquire. The Enquire Control Sequence consists of the single character: <ENQ> 0x10 It is sent in one of two circumstances: o The Responder is in terminal mode and the Initiator wants to synchronize its <Sequence> number, and to tell the Responder to set up for normal B Protocol. When the <ENQ> is received, the Responder must: > Prepare for 512 byte data blocks > Prepare for Standard Checksum > Initialize its Sequence to 0x30 > Transmit the string: <DLE> + + <DLE> 0x30 > Return to terminal mode. Note: The terminal program definately should NOT enter B Protocol mode when the <ENQ> is received. o The entity sending the packet has received a Negative Acknowledge, or timed out while waiting for an Acknowledge. The response to an <ENQ> during a B Plus session is a Positive Acknowledge. 2. Positive Acknowledge. When a correctly checked and sequenced packet is received, a Positive Acknowledge is transmitted. This consists of: <DLE> Sequence where Sequence is the Sequence number of the last validly received packet. 16 3. Wait. The Wait Control Sequence informs the receiving entity that the sending entity requires additional time to process what it has received. Wait is sent as: <DLE> ; 4. Negative Acknowledge. When the receiving entity receives a packet with an unexpected <Sequence>, improper checksum or times out, it sends a Negative Acknowledge to the other entity. This consists of the single byte: <NAK> 0x15 When the sending entity receives a NAK, it initiates a Resynchronization Process by sending two <ENQ> characters and waiting until it receives two identical Positive Acknowlegements. 5. Panic Abort. The B Plus Protocol recognizes a series of four <DLE> characters as a panic abort. The need for such a facility can arise if the Responder computer becomes locked up during a transfer, and it is necessary to reboot. Since <DLE> is really control-P, sending it is a very simple procedure. In addition, the Initiator recognizes the seqeunce: <DLE> + while waiting for a Positive Acknowledge as being incorrect, and will abort the transfer. This can happen as above, but before the operator can press control-P the Initiator sends an <ENQ> during a down-load to find out what is happening. The Responder, now in terminal emulation mode, responds with: <DLE> + + <DLE> 0 and the Initiator will abort cleanly. For this reason it is essential that any B Plus implementation observe the rules for <ENQ>: If in terminal mode, send <DLE> + + <DLE> 0; otherwise send <DLE> Sequence. 17 E. Negotiation of Transport Parameters. The Initiator begins a B Plus protocol session by sending: <ENQ> while the Responder is in terminal mode. The Responder sets itself up for: o Standard Checksum o Default Quoting o 512 byte data block o Sets its Sequence to 0x30 (`0') o transmits the sequence: <DLE> + + <DLE> 0 o returns to terminal mode. The Initiator, detecting the `<DLE> + +', sends a Transport Parameters Packet using Standard Checksum and quoting of 0x00 thru 0x1f and 0x80 thru 0x9f. When the Responder properly receives this packet, it must transmit a Transport Parameters Packet indicating its own parameter settings. Once the Initiator Acknowledges the Responder`s Transport Parameters Packet, each entity then establishes its operating configuration based on the minimal matching parameters. In particular, the Initiator and Responder each choose the minimum of: Own Other's Parameter Parameter WS WR <- Note the cross-comparison of WR WS <- these parameters. BS BS CM CM TL TL DR DR UR UR FI FI and the inclusive-or of the Quoting Sets. For example, if the Initiator sends the sequence: 0x01 0x01 0x08 0x01 0x01 0x00 0x14 0xd4 0x00 0x00 <- Quoting Set 0x00 0x00 0x00 0x00 <- 0x01 0x00 0x00 <- DR UR FI and the Responder returns: 0x00 0x01 0x04 0x00 0x01 0x00 18 0x54 0xd4 0x00 0x00 <- Quoting Set 0x40 0x50 0x00 0x00 <- The following parameters are used by both entities: Parameter Initiator Responder WS 0x01 0x00 Initiator sends 1 packet ahead. WR 0x00 0x01 Responder sends 1 packet and waits for Postive Acknowledge BS 0x04 0x04 Both use 512 byte data body CM 0x00 0x00 Standard Checksum The following characters will be quoted when transmitted by either entity: 0x01 0x03 0x05 0x10 0x11 0x13 0x15 0x81 0x91 0x93 SOH ETX ENQ DLE XON XOFF NAK SOH XON XOFF This would be the quoting used for a Responder having a modem which treats the 0x01 as "Escape to command mode" and in addition responds to flow control characters (0x11 0x13 0x91 0x93). Since the Responder did not transmit the DR, UR, and FI parameters, the initiator sets them to 0x00. The next packet transmitted will be expected to obey the negotiated Transport Parameters. 19 F. Terminal Program States. This section describes the expected state transitions for a terminal program which supports the B Plus Protocol. Current State Event Action Next State ------------------------------------------------------------ Terminal <ENQ> Rcvd. Return: Terminal <DLE> + + <DLE> 0 Set up for normal B Protocol <DLE> Rcvd. None. DLE_Seen <Other> Process as an ASCII char. Terminal ------------------------------------------------------------ DLE_Seen <B> Rcvd. None. Get_First_Packet <other> Rcvd. None. Terminal ------------------------------------------------------------ Get_First_Packet Receive the Packet Valid packet : <+> Process Transport Terminal Parameters; set up for B Plus if successful exchange <T> Invoke Transfer Terminal Process <other> Return Failure Terminal Packet N ------------------------------------------------------------ 20 G. Wait for Acknowledge. The Wait for Acknowledge procedure is the work-horse of the B+ Protocol. It is implemented as a Finite State Automaton having thirteen states as follows: State Description ---------------- ---------------------------------------- S_Get_DLE Wait for <DLE> from Responder. S_DLE_Seen Get character following the <DLE>. S_DLE_B_Seen Receive Packet Sequence Number. S_Get_Data Receive data portion of packet. S_Get_Check Receive check value. S_Get_CRC Receive CRC-16. S_Verify_CRC Compare received to calculated CRC-16. S_Verify_CKS Compare received to calculated checksum. S_Verify_Packet Check for failure packet; verify packet sequence number. S_Send_NAK Count error; send <NAK> to Responder. S_Send_ACK Send ACK sequence to Responder. S_Send_ENQs Count error; Send two <ENQ> characters to Responder. S_Resend_Packets Retransmit packet(s) to Responder. The State Transition table follows: State Event Action Next State ---------------- ------------ ----------------- ----------- S_Get_DLE <DLE> ... S_DLE_Seen <NAK> ... S_Send_ENQ <ENQ> ... S_Send_ACK <ETX> ... S_Send_NAK timeout ... S_Send_ENQ other ... S_Get_DLE S_DLE_Seen <digit> Release Packet return success -or- If <ENQ> sent S_Resend_Packets else S_Get_DLE <B> ... S_DLE_B_Seen <;> ... S_Get_DLE <ENQ> ... S_Send_ACK timeout ... S_Send_ENQ other ... S_Get_DLE S_DLE_B_Seen <ENQ> ... S_Send_ACK <char> Save <char> Intit Check Value S_Get_Data timeout ... S_Send_NAK 21 S_Get_Data <ETX> ... S_Get_Check timeout ... S_Send_NAK <ENQ> ... S_Send_ACK <char> Add <char> to check value Store <char> in buffer S_Get_Data S_Get_Check <char> If Check Method is CRC_16 S_Get_CRC Checksum S_Verify_CKS timeout ... S_Send_NAK S_Get_CRC <char> Add <char> to Received CRC-16 S_Verify_CRC timeout ... S_Send_NAK S_Verify_CRC ... If Received CRC-16 = Calc. CRC-16 S_Verify_Packet else S_Send_NAK S_Verify_CKS ... If Received CKS = Calc. CKS S_Verify_Packet else S_Send_NAK S_Verify_Packet ... If Saved <char> = expected Seq number Return size -or- If Packet Type = `F' Return size If duplicate packet S_Send_ACK else S_Send_NAK S_Send_NAK ... Count Receive Error If too many errors Return failure If not Aborting then Send <NAK> S_Get_DLE S_Send_ACK ... IF not Aborting then Send ACK sequence S_Get_DLE S_Send_ENQ ... Send <ENQ><ENQ> S_Get_DLE S_Resend_Packets ... Send all un-ACKed packets. S_Get_DLE Note: "Aborting" means that a Failure Packet has been sent. If Failure Packet has been sent, all outstanding packets are assumed to be ACKed. 22 H. Packet Send Ahead One of the most useful features of the B Plus Protocol, from the user's point of view, is its ability to send more than one packet ahead of receiving the acknowledgment of the oldest one. This improves thru-put by overlapping the I/O performed on both the Initiator and Responder computers, including the time required for the Responder computer's acknowledgement to arrive at the Initiator and wake up the Initiator's application program. The Packet Send Ahead is accomplished by keeping a set of buffers in memory, one for each permitted outstanding packet. Each buffer contains the corresponding packet's <Sequence>, count, and the data itself. In addition a counter of outstanding packets (ie, not yet ACKed) is maintained and incremented whenever a packet is sent for the first time. Two indicies into the set of buffers are used to keep track of the Send Ahead status. One keeps track of which buffer holds the oldest packet and the other which buffer may be filled with new data. When a packet is about to be sent, the outstanding count is checked to see if the maximum number of outstanding packets has been reached. If so, a routine (GetACK) is invoked which waits for the ACK to arrive for the oldest outstanding packet. Several possibilities exist: o The oldest packet is ACKed. In this case, move the Oldest Outstanding index to point to the next oldest packet and decrement the outstanding packet count. o Some other packet in the buffer pool has been ACKed. This implies an ACK has been missed. Move the Oldest Outstanding index to point to the buffer following the received ACK, and decrement the Outstanding Count accoringly. o A NAK is received. Retransmit all packets which are outstanding. If the Outstanding count is still at the maximum, stay in GetACK. Finally, a procedure is necessary which calls GetACK until either a failure occurs or the Outstanding count is zero. 23 The Send Ahead Process proceeds as follows: Receiver's Packet Sequence Buffer Outstanding Response 1 `1' 0 1 ... 2 `2' 1 2 ... 3 GetACK ACK `1' `3' 0 2 ... 4 GetACK ACK `2' `4' 1 2 ... 5 GetACK ACK `3' `5' 0 2 ... (Last) GetACK ACK `4' 1 ... GetACK ACK `5' 24 I. Implementation Considerations 1. Time-Out A per-character time-out of ten seconds should be used. Using anything less can result in a loss of good control over the exchange of packet and control sequences. If conditions over a switched network degrade sufficiently, a small time out can lead to excessive retransmissions of data. On the other hand, longer time-out values will result in a more sluggish detection of protocol breakdown. The receiving entity should be silent when a timeout occurs. That is, a <NAK> should not be sent when a timeout occurs while receiving a packet. The reason is that under severely degraded network loading it may happen that it takes longer for the sending entity's data to arrive than the receiving entity's timeout interval. This can lead to many kinds of situations in which there is excessive retransmission of data. The question to be answered by the implementor is: "Am I more concerned about how fast I can shut down the transfer when the sending entity goes away than I am about getting the transfer to occur regardless of how long it takes?" If the answer is that response to a vanished sender is more important, then send a <NAK> when a timeout occurs. If getting the job done is more important, then don't send the <NAK> on timeout. 2. Packet Size. The following chart shows the percentage of houskeeping overhead for various packet sizes (not including quoted characters): Packet Data Packet Transmission Time Size Size Useful Overhead 300 1200 2400 ---- ------ ------ -------- ---- ---- ---- 128 135 94.8 % 5.2 % 4.5 1.1 0.6 256 263 97.3 % 2.7 % 8.8 2.2 1.1 384 391 97.7 % 2.3 % 13.0 3.3 1.6 512 519 98.7 % 1.3 % 17.3 4.3 2.2 640 647 98.9 % 1.1 % 21.6 5.4 2,7 768 775 99.1 % 0.9 % 25.8 6.5 3,2 896 903 99.2 % 0.8 % 30.1 7.5 3.8 1024 1031 99.3 % 0.7 % 34.4 8.6 4.3 At first glance it might seem reasonable to always use 1024 byte data packets. However, consideration should be given to the amount of time required to recover from a transmission error. For example, using 1024 byte data packets at 300 baud, over a minute of excessive transmission time would result (two packets) each time an error occured. Experience shows that keeping the packet transmission time to between four and five seconds results in a reasonably comfortable recovery time. So, for best 25 over-all performance, the following packet sizes are recommended: Baud Size ---- ---- 300 128 1200 512 2400 1024 3. Controlling Excessive Retransmissions. Over a very noisy link the send-ahead nature of B Plus might cause the performance to degrade due to retransmission of packets. To circumvent this degradation, the following heuristic is recommended: Initialize SA_Error_Count to zero. If packets are retransmitted, increment SA_Error_Count by 3. If SA_Error_Count is greater than or equal to 12, drop out of Send-Ahead mode (ie, revert to send and wait mode). When a packet is ACKed, and SA_Error_Count is greater than zero, decrement SA_Error_Count by one. The values (increment by 3, limit of 12, decrement by 1) can be varied in accord with the implementor's experience, perhaps being established by user-definable parameters. 26 J. B Plus Transport Layer. Some distributed applications (that is, applications in which the Initiator and Responder each perform some of the work) require that blocks of information be exchanged. Running such applications over normal communication channels can cause loss or altering of data, yielding unpredictable results. To aleviate this possibility, the B Plus Protocol provides the ability to use the underlying packet structure to exchange blocks of data with error detection and retransmission. Entering the Transport Layer operation is more complicated than the File Transfer mode previously described: o The user invokes a CompuServe application o The application program transmits a CompuServe Application Protocol escape sequence. o The user's terminal program responds with an escape sequence which informs the host application that it must use the Transport Layer. o The host program initializes its B Plus routines, setting the Transport Layer parameter to 0x01. o The terminal program waits until its own B Plus routines have been initialized, also setting the Transport Layer parameter to 0x01. o Once the host and remote B Plus routines have exchanged their Transport Layer Parameters, the Transport Layer is in effect. The succeeding action is a function of the application. From an implementation standpoint, the primary differences from the B Plus Protocol so far described are: o Separate Packet Sequence Numbers are maintained for sending and receiving. o Received Packets are placed in a first-in-first-out queue. o Another level of software is placed between the packet handlers and the application. This level is responsible for sending and receiving blocks of data, packaging them into protocol-sized packets. The following Packet Types are used in the Transport Layer: `M': This is a data packet; another data packet follows. `L': This is the last data packet for the current block. A Failure Packet will terminate the transport layer for both entities. 27 K. Initiation of a B Plus Session. The following state machine describes the process of a host entity initiating a B Plus Session. Its starting state is Send_ENQ. State Received Action Next State ------ -------- ---------------------- ---------- Send_ENQ ... Transmit <ENQ> Set Standard Checksum Set 512 byte Data Block Set default quote set Clear Plus_Seen and Plus_Plus flags Get_DLE ----------------------------------------------------------- Get_DLE <DLE> ... Get_Digit <+> If Plus_Seen true, then set Plus_Plus ... Get_DLE timeout Send_ENQ ------------------------------------------------------------ Get_Digit <digit> Initialize Send and Receive Sequence Numbers Send_Parameters <+> Set Plus_Seen Get_DLE timeout ... Send_ENQ ------------------------------------------------------------ Send_Parameters ... If Plus_Seen true, then if Plus_Plus true, then set to quote 0x00-0x1f and 0x80-0x9f Send Parameters Packet Receive Parameters Packet Establish session's parameters Exit ------------------------------------------------------------- 28 L. Supporting the Various B Protocol Versions There are three versions of B Protocl which an implementor must be aware of. Any new implementation should follow the B Plus Protocol as described in this document to ensure full compatibility with all existing CompuServe Host software. The three versions are: o "Classic" B Protocol o An interim version of B Plus (called Quick B) o B Plus as described in this document The differences are: Initial <ENQ> response: Classic B: <DLE> digit QuickB: <DLE> + <DLE> digit B Plus: <DLE> + + <DLE> digit Default Quoting Sets: Classic B: 0x00 -> 0x1f QuickB: 0x00 0x03 0x05 0x10 0x11 0x13 0x15 B Plus: 0x03 0x05 0x10 0x11 0x13 0x15 Extended Quoting: Classic B: none QuickB: Specified by the DQ Parameter: 0x00 : 0x00 0x03 0x05 0x10 0x11 0x13 0x15 0x01 : 0x03 0x05 0x10 0x11 0x13 0x15 0x02 : 0s03 0x05 0x10 0x11 0x13 0x15 0x91 0x93 0x03 : 0x00-0x1f and 0x80-0x9f B Plus: Established by the Q1 thru Q8 parameters. (Ignore R0) Quoting of the Paramters Packet: Classic B: No paramaters packet QuickB: 0x00 -> 0x1f B Plus: 0x00 -> 0x1f and 0x80 -> 0x9f Response to a <NAK>: Classic B: Retransmit the last packet QuickB: Resynchronize with <ENQ><ENQ>, wait for two identical ACK sequences, retransmit as necessary. B Plus: Same as QuickB. 29 CompuServe Host software will support all three B Protocol versions. In order to do so, it relies on the initial response to <ENQ> to determine what version is being used in the terminal software. The defaults given in Section D.1 ("Enquire") are intended to reflect "Classic" B Protocol. If the Host receives <DLE> <+> <DLE> <digit> it sends its Transport Parameters Packet using "Classic" B data quoting (0x00 -> 0x1f). If two "+" chracters are received, it will quote 0x00 -> 0x1f and 0x80 -> 0x9f. This is done to maximize the chances of getting the packet through most modems and networks. Once the Transport Parameters Packets have been successuflly exchanged, the Host software uses the negotiated quoting set, and the remote is expected to do likewise. Negotiation of quoted characters allows implementors to provide configuration set up to cope with a wide variety of modems, oeprating system, network, and other situations which can adversely affect thr transmission of 8-bit binary data. 30 M. Check Value Calculation. 1. Standard B Protocol Checksum. The following C-language code fragment illustrates the Standard Checksum calculation: int checksum; do_checksum (ch) unsigned int ch; { checksum = checksum << 1; if checksum > 0xff checksum = (checksum & 0xff) + 1; checksum += ch & 0xff; if checksum > 0xff checksum = (checksum & 0xff) + 1; }; 31 2. XMODEM-Style CRC-16. /* * Calculates XMODEM-style CRC (uses the CCITT V.41 * polynomial but * completely backwards from the normal bit ordering). */ static unsigned crc_xmodem_tab[] = { 0x0000,0x1021,0x2042,0x3063,0x4084,0x50A5,0x60C6,0x70E7, 0x8108,0x9129,0xA14A,0xB16B,0xC18C,0xD1AD,0xE1CE,0xF1EF, 0x1231,0x0210,0x3273,0x2252,0x52B5,0x4294,0x72F7,0x62D6, 0x9339,0x8318,0xB37B,0xA35A,0xD3BD,0xC39C,0xF3FF,0xE3DE, 0x2462,0x3443,0x0420,0x1401,0x64E6,0x74C7,0x44A4,0x5485, 0xA56A,0xB54B,0x8528,0x9509,0xE5EE,0xF5CF,0xC5AC,0xD58D, 0x3653,0x2672,0x1611,0x0630,0x76D7,0x66F6,0x5695,0x46B4, 0xB75B,0xA77A,0x9719,0x8738,0xF7DF,0xE7FE,0xD79D,0xC7BC, 0x48C4,0x58E5,0x6886,0x78A7,0x0840,0x1861,0x2802,0x3823, 0xC9CC,0xD9ED,0xE98E,0xF9AF,0x8948,0x9969,0xA90A,0xB92B, 0x5AF5,0x4AD4,0x7AB7,0x6A96,0x1A71,0x0A50,0x3A33,0x2A12, 0xDBFD,0xCBDC,0xFBBF,0xEB9E,0x9B79,0x8B58,0xBB3B,0xAB1A, 0x6CA6,0x7C87,0x4CE4,0x5CC5,0x2C22,0x3C03,0x0C60,0x1C41, 0xEDAE,0xFD8F,0xCDEC,0xDDCD,0xAD2A,0xBD0B,0x8D68,0x9D49, 0x7E97,0x6EB6,0x5ED5,0x4EF4,0x3E13,0x2E32,0x1E51,0x0E70, 0xFF9F,0xEFBE,0xDFDD,0xCFFC,0xBF1B,0xAF3A,0x9F59,0x8F78, 0x9188,0x81A9,0xB1CA,0xA1EB,0xD10C,0xC12D,0xF14E,0xE16F, 0x1080,0x00A1,0x30C2,0x20E3,0x5004,0x4025,0x7046,0x6067, 0x83B9,0x9398,0xA3FB,0xB3DA,0xC33D,0xD31C,0xE37F,0xF35E, 0x02B1,0x1290,0x22F3,0x32D2,0x4235,0x5214,0x6277,0x7256, 0xB5EA,0xA5CB,0x95A8,0x8589,0xF56E,0xE54F,0xD52C,0xC50D, 0x34E2,0x24C3,0x14A0,0x0481,0x7466,0x6447,0x5424,0x4405, 0xA7DB,0xB7FA,0x8799,0x97B8,0xE75F,0xF77E,0xC71D,0xD73C, 0x26D3,0x36F2,0x0691,0x16B0,0x6657,0x7676,0x4615,0x5634, 0xD94C,0xC96D,0xF90E,0xE92F,0x99C8,0x89E9,0xB98A,0xA9AB, 0x5844,0x4865,0x7806,0x6827,0x18C0,0x08E1,0x3882,0x28A3, 0xCB7D,0xDB5C,0xEB3F,0xFB1E,0x8BF9,0x9BD8,0xABBB,0xBB9A, 0x4A75,0x5A54,0x6A37,0x7A16,0x0AF1,0x1AD0,0x2AB3,0x3A92, 0xFD2E,0xED0F,0xDD6C,0xCD4D,0xBDAA,0xAD8B,0x9DE8,0x8DC9, 0x7C26,0x6C07,0x5C64,0x4C45,0x3CA2,0x2C83,0x1CE0,0x0CC1, 0xEF1F,0xFF3E,0xCF5D,0xDF7C,0xAF9B,0xBFBA,0x8FD9,0x9FF8, 0x6E17,0x7E36,0x4E55,0x5E74,0x2E93,0x3EB2,0x0ED1,0x1EF0}; unsigned CRC; UpdCrc (Byte) unsigned int ByteC; { CRC = crc_xmodem_tab [(CRC >> 8 ^ Byte) & 0xff] ^ (crc << 8); }; 32 N. Interrogation. Although not part of the B Plus Protocol, implementors are urged to support the CompuServe Interrogation Sequence. This process passes information to the CompuServe Host to identify the various options supported by the terminal program. Host software will generally perform an Enquire (Section D.1) first to determine if the terminal program supports B Protocol. If B Protocl ("Classic," QuickB, or B Plus) is supported, the host then sends the sequence: <ESC> I When the terminal program receives this sequence of characters, it transmits an Interrogation Response as follows: <#> <Mod> <Ver> <F-codes> <+> <Check> <CR> where: <#> Identifies the string as an Interrogation Response <Mod> Specifies the specific hardware or operating system, or a generic class of software. It is always three characters in length. In addition to several reserved codes, the following generic codes are defined: APX - Apple (TM) II/Macintosh ATX - Atari (TM) 8, 16, and 32 bit AUT - Auto-Script Program CCX - Commodore (TM) C64 and Amiga CPM - CP/M (TM) Operating System IBX - IBM (TM) Compatible XXX - Other model/type <Ver> Gives the terminal software version number. It may contain Letters, Digits, and Periods. <F-codes> A series of character fields giving the options supported. Each <F-code> is followed by a comma. The currently recognized <F-codes> are as follows: Cursor/Screen Control AC : ANSI Color CA : ANSI/VT100 Cursor Control CC : VIDTEX/VT52 Cursor Control CW : Wide mode (Double width characters invoked by <ESC> <m> uninvoked by <ESC> <l> (lower case L) SSyx : Screen Size; y gives number of lines + 31, x gives number of 33 columns plus 31. SS7o identifies a 24 line by 80 column screen. It is suggested that the SS field always be present. Graphics GF : GIF graphics GH : High resolution RLE graphics GM : Medium resolution RLE graphics NF : Full NAPLPS graphics Protocols AP : Recognizes and properly responds to the CompuServe Application Protocol escape sequences CB : Capture Buffer PB : B Protocol (includes QuickB and B Plus) PX : XMODEM Miscellaneous HC : Hard Copy (printer connected) XX : Ignored All other <F-codes> are reserved for future use. <Check> This is a check value derived by adding together all characters in the Interrogate Response up to and including the +, truncating the sum to 16 bits, and converting it to an ASCII digit string. <CR> This is the ASCII Carriage Return and serves to terminate the Interrogate Response. If the <Check> value does not match, the host will send another <ESC> I and compare the string it receives to the previous one. If the two strings match, it is accepted, otherwise the <ESC> I and matching will continue for ten trials before giving up. 34 A sample Interrogate Response is: #IBX,CC,GH,GM,PB,+1035<CR> which specifies: o IBX : An IBM (TM) compatible system o CC : Supports standard VIDTEX/VT52 cursor controls o GH : Supports high-resolution RLE graphics o GM : Supports medium-resulution RLE graphics o PB : Supports B Protocol o 1035: Sum of "#IBM,CC,GH,GM,PB,+" For additional information concerning the Interrogation Response, please contact CompuServe Incorporated, Microcomputer Software Development. 35